Seeding challenges for payment transactions

ABSTRACT

Systems, methods, and apparatus are provided for authenticating a consumer using challenge questions. A response to a challenge question is verified via seeding the challenge question, receiving response, and deductively determining the answer. The verified response and challenge question may then be used to authenticate a consumer as part of an authorization process.

CLAIM OF PRIORITY

The present application is a divisional application of U.S. patentapplication Ser. No. 12/140,215, filed Jun. 16, 2008, now U.S. Pat. No.8,380,629, issued Feb. 19, 2013, which is a non-provisional applicationof and claims priority to U.S. Provisional No. 60/946,113, filed on Jun.25, 2007, the entire contents of which are herein incorporated byreference for all purposes.

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application is related to U.S. patent application Ser. No.11/763,240, filed on Jun. 14, 2007, which is incorporated by referencein its entirety for all purposes.

BACKGROUND OF THE INVENTION

The present application is generally related to payment transactions,and more specifically to the use of challenge questions in authorizing atransaction.

It is desirable to have mechanisms that ensure that a consumer who isusing a portable consumer device such as a credit card is really theconsumer who is associated with the credit card. Fraudulent activity canbe very costly to merchants, issuers of portable consumer devices, andothers.

A number of consumer authentication mechanisms are known. In one exampleof a conventional consumer authentication process, a consumer maypurchase gas at a gas station using his credit card. Before the consumeris allowed to buy the gas and before the authorization request messageis sent to the issuer of the portable consumer device, the gas pump mayrequest that the consumer supply his zip code. The answer supplied bythe consumer is then compared against a zip code obtained, for example,from the records of the issuer of the credit card or records from someother third party.

This authentication request may be provided by the merchant as a way toensure that the consumer is in fact the consumer associated with thecredit card. The gas station wants to verify that the consumer isauthentic, since the gas station may bear some of the risk for anyfraudulent activity that results from purchases made at the gas station.

While such conventional authentication methods have some effectiveness,there are still problems. For example, conventional authenticationrequests typically reuse the same questions. If someone has stolen aconsumer's portable consumer device and knows the consumer's zip code(possibly obtained from the same third party), for example, that personcould still conduct fraudulent transactions using the authentic portableconsumer device. As there may be limited number of known data that canbe used as a correct answer to a question posed to the consumer, it maynot be hard for a thief to obtain such information. The data may bepublic (e.g., in a phone listing or on the Internet) or obtainable forpurchase from a third party if requested under false pretenses.

Better ways to authenticate consumers using portable consumer devicesare desirable. Embodiments of the invention address the above problems,and other problems, individually and collectively.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the invention can be used to seed and deductively verifya response to a challenge question. The verified response and challengequestion may then be used to authenticate a consumer as part of anauthorization process. In this manner, an entity or system that is usedto create challenge questions is less likely to be compromised and cangenerate valid data for posing challenge questions without having torely on buying or receiving the data from a third party.

One embodiment of the invention is directed to a method comprisingproviding a challenge message to a consumer, wherein a correct responseto the challenge message is not known by an entity issuing the challengemessage. A first challenge response that is responsive to the challengemessage is received from the consumer. Providing the challenge messageto the consumer and receiving a subsequent challenge response are thenrepeated during each of one or more processes for authorizing arespective transaction requested by the consumer. In some embodiments,none of the subsequent challenge responses are used in a determinationof whether the consumer is authorized to make any of the respectivetransactions. Subsequent challenge responses may be generated bytransactions conducted by the consumer at various locations and/or withvarious different merchants. A verified answer to the challenge messageis inferred based at least on a similarity of the received challengeresponses. The challenge message, the verified answer, and anotherchallenge response that is responsive to the challenge message is thenused in a process for determining whether the consumer is authorized tomake another transaction.

Another embodiment of the invention is directed to a method where aconsumer receives from an entity a challenge message for a first time.The consumer provides to the entity a first challenge response that isresponsive to the challenge message. Receiving the challenge message andproviding a subsequent challenge response is then repeated during eachof one or more processes for authorizing a respective transactioninitiated by the consumer. The subsequent challenge responses areprovided to facilitate a verification of an answer to the challengemessage. In some embodiments, none of the subsequent challenge responsesaffect whether the consumer is authorized to make any of the respectivetransactions.

An authorization request message, which is associated with a consumerconducting another transaction with a portable consumer device, isinitiated and sent to an issuer associated with the portable consumerdevice. The consumer receives from the entity the challenge messageduring a process for authorizing the another transaction. The consumerprovides the entity with another challenge response. The consumer thenreceives an authorization response message that indicates whether or notthe another transaction is authorized. The another transaction is morelikely to be authorized if the another challenge response is similar tothe verified answer.

Other embodiments of the invention are directed to systems, portableconsumer devices, and computer readable media associated with theabove-described methods.

These and other embodiments of the invention are described in furtherdetail below with reference to the Figures and the Detailed Description.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram illustrating a method for authorizing atransaction that may be improved by an embodiment of the presentinvention.

FIG. 2 shows an exemplary system according to an embodiment of thepresent invention.

FIG. 3 is a flow diagram illustrating a method for determining averified response to a challenge question and using the verifiedresponse in an authorization process according to an embodiment of thepresent invention.

FIG. 4 is a flow diagram illustrating a method for determining achallenge to use in an authorization process according to an embodimentof the present invention.

FIG. 5 is a flow diagram illustrating a method for determining averified response during an authorization process according to anembodiment of the present invention.

FIG. 6 is a flow diagram illustrating a method for performing anauthorization of a transaction using a verified challenge responseaccording to an embodiment of the present invention.

FIG. 7 shows a block diagram of a computer apparatus.

DETAILED DESCRIPTION OF THE INVENTION

Currently, consumer authentication using challenge questions istypically performed at the merchant. The merchant asks the consumer foridentification such as a driver's license before allowing a purchasetransaction with a portable consumer device to proceed. In some cases,it may be better to use data that have been collected by the entityposing the challenge questions. This data (responses to the challengequestions) may not be publicly available or at least not easilyobtainable by a thief. Thus, such data is more secure and such data doesnot have to be purchased from another party.

Once a response to a challenge question has been sufficiently verified,the verified challenge and response may then be used to authenticate aconsumer as part of a process for authorizing a transaction. Forexample, if the consumer answers the challenge question with theverified response, the consumer is more likely to be consideredauthenticated and authorized to make the transaction. In addition, theissuer and the payment processing organization have information such asrecent purchase information and consumer purchasing behavior. Any ofthis information can also be used in authorizing a purchase transaction.

Some embodiments of the invention can be used with standard paymentprocessing systems. Exemplary payment processing systems are describedin further detail below.

The term verified as used herein means that the response has been deemedworthy to be used in some manner for determining whether a transactionrequested by a consumer will be authorized. Up until verification, theresponses are merely collected to deduce a verified response.

I. Authorization Using Challenges

FIG. 1 is a flow diagram illustrating a method 100 for authorizing atransaction that may be improved by an embodiment of the presentinvention. In a typical purchase transaction, a consumer purchases agood or service at a merchant using a portable consumer device, such asa credit card. The consumer's portable consumer device can interact withan access device such as a POS (point of sale) terminal at the merchant.Typically, the interaction causes an authorization request to be sent toan authorization system, which may be termed an initiation of theauthorization request message. The authorization request messages mayhave information such as BINs (bank identification numbers), transactionamounts, account numbers, service codes, etc.

In step 105, the authorization system receives the authorization requestmessage. In one embodiment, the first authorization request message issent through a payment processing network and received at a paymentprocessing network server and the payment processing network server.

In step 110, it is determined if a challenge is needed. Various criteriamay be used to determine if a challenge is needed. For example, thepayment processing network server may determine that the particulartransaction is a high value transaction (e.g., greater than $1000) andthat a challenge is therefore appropriate. In another example, thepayment processing network server may determine that there is somethingsuspicious about the present transaction and may thereafter determinethat a challenge is appropriate. For example, the payment processingnetwork server may determine that the portable consumer device iscurrently being used at a location which is different from theconsumer's home state, and the consumer's recent purchase historysuggests that the consumer is not traveling.

In step 115, a challenge question may then be selected or fetched, e.g.,from a challenge question database. In step 120, the authorizationsystem sends an authorization response message to the access device viathe merchant. The first authorization response message may contain datarepresenting the challenge question or an order to the access device toissue a challenge based on a set of preloaded question in the accessdevice. Once the challenge question is received at the access device,the consumer supplies the challenge response to the access device. Thechallenge response may be supplied to the access device in any suitablemanner (e.g., through a keypad, contactless reader, etc.). The accessdevice can then forward the challenge response to the authorizationsystem.

In step 125, the authorization system receives the challenge response.The challenge response (or the challenge and response or the challengepointer and response) message may be part of a second authorizationrequest message. In step 130, the payment processing network server canthen validate the challenge response message.

If the challenge response message is not validated, then the paymentprocessing network server may send a response message back to the accessdevice indicating that that transaction is not approved. If thechallenge response message is validated, the authorization system maysend an approval to the access device or may send an indication toanother system or party (e.g. an issuer) that the consumer has satisfiedany challenges posed by the payment processing network. The issuer maythen approve or disapprove the transaction based on other criteria.

At the end of the day, a normal clearing and settlement process can beconducted by the transaction processing system. A clearing process is aprocess of exchanging financial details between and acquirer and anissuer to facilitate posting to a consumer's account and reconciliationof the consumer's settlement position. Clearing and settlement can occursimultaneously.

The method described with respect to FIG. 1 can be characterized as a“closed channel” process since the access device receives a challengequestion and provides a response to the challenge question. However,other embodiments of the invention may use open channel solutionswhereby a challenge question may be sent to a device other than theaccess device which sent the first authorization response message.

FIG. 2 shows an exemplary system 20 according to an embodiment of thepresent invention. Other systems according to other embodiments of theinvention may include more or less components than are shown in FIG. 2.

The system 20 shown in FIG. 2 includes a merchant 22 and an acquirer 24associated with the merchant 22. In a typical payment transaction, aconsumer 30 may purchase goods or services at the merchant 22 using aportable consumer device 32. The acquirer 24 can communicate with anissuer 28 via a payment processing network 26. The merchant 22 couldalternatively be connected directly to the payment processing network26. The consumer 30 may be an individual, or an organization such as abusiness that is capable of purchasing goods or services. The consumer30 may optionally operate a wireless phone 34.

The portable consumer device 32 may be in any suitable form. Forexample, suitable portable consumer devices can be hand-held and compactso that they can fit into a consumer's wallet and/or pocket (e.g.,pocket-sized). They may include smart cards, ordinary credit or debitcards (with a magnetic strip and without a microprocessor), keychaindevices (such as the Speedpass™ commercially available from Exxon-MobilCorp.), etc. Other examples of portable consumer devices includecellular phones, personal digital assistants (PDAs), pagers, paymentcards, security cards, access cards, smart media, transponders, and thelike. The portable consumer devices can also be debit devices (e.g., adebit card), credit devices (e.g., a credit card), or stored valuedevices (e.g., a stored value card).

An exemplary portable consumer device in the form of a phone maycomprise a computer readable medium and a body. The memory of thecomputer readable medium preferably stores information such as financialinformation, transit information (e.g., as in a subway or train pass),access information (e.g., as in access badges), etc. Financialinformation may include information such as bank account information,bank identification number (BIN), credit or debit card numberinformation, account balance information, expiration date, consumerinformation such as name, date of birth, etc. Any of this informationmay be transmitted by the portable consumer device 32.

The portable consumer device 32 may further include a contactlesselement, which is typically implemented in the form of a semiconductorchip (or other data storage element) with an associated wirelesstransfer (e.g., data transmission) element, such as an antenna.

The portable consumer device 32 may also include a processor (e.g., amicroprocessor) for processing the functions of the portable consumerdevice 32 and a display to allow a consumer to see phone numbers andother information and messages. The portable consumer device 32 mayfurther include input elements to allow a consumer to input informationinto the device, a speaker to allow the consumer to hear voicecommunication, music, etc., and a microphone to allow the consumer totransmit her voice through the portable consumer device 32. The portableconsumer device 32 may also include an antenna for wireless datatransfer (e.g., data transmission). These characteristics may also bepresent in the phone 34.

The payment processing network 26 may include data processingsubsystems, networks, and operations used to support and deliverauthorization services, exception file services, and clearing andsettlement services. An exemplary payment processing network may includeVisaNet™. Payment processing networks such as VisaNet™ are able toprocess credit card transactions, debit card transactions, and othertypes of commercial transactions. VisaNet™, in particular, includes aVIP system (Visa Integrated Payments system) which processesauthorization requests and a Base II system which performs clearing andsettlement services.

The payment processing network 26 may include a server computer. Aserver computer is typically a powerful computer or cluster ofcomputers. For example, the server computer can be a large mainframe, aminicomputer cluster, or a group of servers functioning as a unit. Inone example, the server computer may be a database server coupled to aWeb server. The payment processing network 26 may use any suitable wiredor wireless network, including the Internet.

As shown in FIG. 2, the payment processing network 26 may comprise aserver 26(a), which may comprise a challenge question engine 26(a)-1.The server 26(a) may also be in communication with a transaction historydatabase 26(b) and a challenge question database 26(c). As will beexplained in further detail below, the challenge question engine 26(a)-1may simply extract challenge questions from the challenge questiondatabase 26(c). Alternatively or additionally, the challenge questionengine 26(a)-1 may generate challenge questions using information in thetransaction history database 26(b).

The challenge question database 26(c) may be populated with questions ofany suitable type. The questions may relate to a past location (e.g.,the consumer's current home, the city that the consumer recentlyvisited) or current location (e.g., the current location of the storethat the consumer is currently at), the type or name of the merchantthat the consumer is presently visiting or has visited in the past, theconsumer's family or personal data (e.g., name, phone number, socialsecurity number, etc.), etc. The questions in the challenge questiondatabase 26(c) may be generated by the challenge question engine 26(a)-1and subsequently stored in the challenge question database 26(c).

Alternatively, or additionally, the challenge questions may be generatedfrom an external source and then subsequently stored in the challengequestion database 26(c). For example, the consumer 30 may use a browseron a personal computer or the like to supply specific challengequestions to the server 26(a) via a communication medium (not shown)such as the Internet.

The merchant 22 may also have, or may receive communications from, anaccess device 36 that can interact with the portable consumer device 32.The access devices according to embodiments of the invention can be inany suitable form. Examples of access devices include point of sale(POS) devices, cellular phones, PDAs, personal computers (PCs), tabletPCs, handheld specialized readers, set-top boxes, electronic cashregisters (ECRs), automated teller machines (ATMs), virtual cashregisters (VCRs), kiosks, security systems, access systems, and thelike.

The issuer 28 may be a bank or other organization that may have anaccount associated with the consumer 30. The issuer 26 may operate aserver 28(a) which may have a challenge question engine 28(a)-1. Atransaction history database 26(b) and a challenge question database28(c) may be in communication with the server 28(a). The issuer server28(a), challenge question engine 28(a)-1, transaction history database26(b), and challenge question database 28(c) may operate in the same wayor a different way than the payment processing network server 28(a),challenge question engine 28(a)-1, transaction history database 28(b),and challenge question database 28(c). The above-descriptions as toelements 26(a), 26(a)-1, 26(b), and 26(c) may apply to elements 28(a),28(a)-1, 28(b), and 28(c).

Embodiments of the invention are not limited to the above-describedembodiments. For example, although separate functional blocks are shownfor an issuer, payment processing network, and acquirer, some entitiesperform all or any suitable combination of these functions and may beincluded in embodiments of invention. Additional components may also beincluded in embodiments of the invention.

As mentioned above, it is desirable to seed challenge questions anddeduce (infer) verified responses for use in the authentication process.

II. Authorization Using Seeded Challenges

FIG. 3 is a flow diagram illustrating a method 300 for determining averified response to a challenge question and using the verifiedresponse in an authorization process according to an embodiment of thepresent invention. Method 300 may be performed, for example, when acorrect answer is not known to any number of challenge questions, whennew challenge questions and corresponding responses are desired, and/orwhen a proprietary access to data is desired. Reference is also made toFIG. 2.

In step 302, seeding is performed to deduce a verified response to achallenge question. During seeding, a challenge question is proposed tothe consumer, who then responds with a response to the challenge. Thiscan be done multiple times. For example, the challenge question may bepresented to the consumer 30 via the access device 36 or the mobilephone 34. The challenge question may originate from the issuer 28 or thepayment processing network 26. A response is verified after the consumer30 consistently provides the same or similar response. Up untilverification, the responses are merely collected to deduce a verifiedresponse, and may not be actively used in an authorization process. Thatis, the challenge response does not impact or affect the authorizationoutcome, until the response to the challenge question is verified. Thisseeding/deducing process will be discussed in detail below.

In step 305, the authorization system receives an authorization requestmessage. For example, the issuer 28 may receive an authorization requestmessage from the merchant 22 via the acquirer 24 and the paymentprocessing network 26 after the consumer 30 interacts with the accessdevice 36 using the portable consumer device 32. In step 310, it isdetermined if a challenge should and/or can be made. For example, theissuer 28 and/or the payment processing network 26 can determine if achallenge should and/or can be made. In addition to criteria previouslymentioned for determining whether a challenge is needed the followingcriteria may be used.

To determine whether a challenge should be made, it may be ascertainedwhether the issuer 28 participates in an authorization program. Anothercriteria is whether the issuer 28 or the payment processing network 26makes the challenge decision. Another criteria is whether there is anavailable challenge channel, e.g., means for the consumer to view achallenge question and respond accordingly. The channel may flowdirectly to the merchant or may bypass the merchant and flow directly tothe consumer, e.g. through his phone. Another criteria is whether or notthe merchant is trusted or exempt, e.g., a merchant who used a type ofbiological identification (fingerprint, retina scan, etc.) may betrusted. Repeat customers to a specific merchant may also be exempt. Forexample, if a customer regularly uses a gas station near his home, thatcustomer can be considered authentic without challenge. Further, aconsumer may also be exempt if an advanced (initial) authorization scorefor the transaction is excellent, which may be based on criteriamentioned herein. These criteria may be used to determine whether or notto issue a challenge.

To determine whether a challenge and/or what type of challenge can bemade, it may be ascertained what is the form factor that the consumer isattempting initiate the transaction, e.g., whether the person is makingthe purchase over the Internet, at a brick and mortar business, orthrough a mobile device. If the person, is making the purchase over theInternet then he/she will be able to answer any type of question with akeyboard. A separate pop up window may be used for implementingchallenge process. In contrast, brick and mortar stores may not haveaccess to a keyboard, and thus possibly no challenges may be made, onlyyes or no questions, or possibility only limited to numeric answers.

Additionally, if there is no form factor at or through the merchant 22,then it may be checked whether the consumer 30 may be contacted directlywith the challenge question. For example, a text message may be sent tothe consumer's phone 34 with a challenge question to be answered.

In step 315, if a challenge should and can be made, a challenge questionmay then be selected or fetched, e.g., from a challenge questiondatabase 28(c). In step 320, the authorization system, which can includethe issuer 28 or the payment processing network 26, sends anauthorization request message to the access device 36, e.g., via themerchant 22. The first authorization request message may contain datarepresenting the challenge question or an order to the access device 36to issue a challenge based on a set of preloaded question in the accessdevice 36. Once the challenge question is received at the access device36, the consumer 30 supplies the challenge response to the access device36. The access device 36 can then forward the challenge response to theauthorization system including the issuer 28 via the merchant 22,acquirer 24, and the payment processing network 26.

The questions asked may also have static or dynamic (semi-dynamic orfully dynamic) answers. For example, the question “What is yourbirthday?” requires a static answer, since the answer does not change.The question “What is your zip-code?” requires a semi-dynamic answer,since it could change or can change infrequently. Note that multiplechallenge questions may be used during a single authorization process.

In step 325, the authorization system including the issuer 28 receivesthe challenge response from the consumer 30. In step 330, the issuerserver 28(a) (or the payment processing network server 26(a) can thenvalidate the challenge response message, which at some confidence levelauthenticates the identity of the consumer 30.

In step 335, after the challenge response has been validated as beingcorrect or incorrect, a risk score may be provided to the issuer 28 foruse in determining whether to authorize the transaction. The risk scoremay account for correctness of the challenge response, the place ofpurchase, the history of the card, the amount of the purchase, or anycombination of the other criteria mentioned herein. Thus, if anincorrect response is provided, the transaction is not necessarilydenied. Also, more than one challenge can be used. If two challenges areused and the response to both are wrong, then there would be a greaterchance that person would be turned down, i.e. a greater risk score. Ifone is wrong and the other right, then the total contribution to therisk score from the challenges may be zero or dependent on theconfidence score (see below) of each challenge. One skilled in the artwill appreciate the different contributions arising from multiplechallenge questions.

The seeding process may be first started when a customer fills out aform, e.g., over the Internet. However, this one time occurrence doesnot establish enough consistency. Thus, at least some of the seedingprocess also occurs during an authorization process that does not usethe challenge response to the particular challenge question that isbeing seeded. That is, the challenge response does not affect (is not afactor of) whether the transaction will be authorized. In oneembodiment, all of the challenge responses are obtained during one ormore authorization processes.

FIG. 4 is a flow diagram illustrating a method 400 for determining achallenge to use in an authorization process according to an embodimentof the present invention. In step 405, the authorization systemincluding payment processing network 26 (and/or the issuer 28) receivesan authorization request message from the consumer 30 via the merchant22, acquirer 24, and the payment processing network 26. In step 410, itis determined if a challenge should and/or can be made.

In step 420, if a challenge should and can be made, it is determinedwhether at least one challenge with a response that has already beenverified exists. This may be present in the challenge question database26(c). If a verified response already exists, one or more verifiedchallenges are selected from the database 26(c) by the challengequestion engine 26(a)-1. The authorization request may then be processedas in method 300 from step 320 and on.

In step 430, if there is not a verified challenge, it is determined(e.g., by the payment processing network server 26(a) or the issuerserver 28(a)) whether an unverified challenge exists in a format thatthe merchant 22 can process, or the consumer 30 can directly process. Ifan unverified challenge does exist in a format that the merchant 22 canprocess, then one or more of the unverified challenges are selected instep 435 (e.g., by the payment processing network server 26(a) or theissuer server 28(a). Accordingly, time and effort is advantageously notwasted trying to receive a challenge response that cannot be provided.

In step 445, the selected unverified challenge is sent to the consumer30 via the access device 36, mobile phone 34, or even the portableconsumer device 32 (if the portable consumer device 32 is a phone orcomputer). The response from the consumer 30 is received at the paymentprocessing network 26 and/or the issuer 28. As noted later, if theresponse shows a consistency that makes the challenge verified with thatparticular response, it may be used in the calculation of the riskscore. Thus, the term verified can mean that the response is used insome manner to determine whether the transaction will be authorized.

If an unverified challenge does not exist in a format that the merchant22 can process, then at step 440 a challenge is optionally created in aformat that the merchant 22 can process. In step 445, the newly createdunverified challenge may also be sent to the consumer 30 (e.g., via theaccess device 36) and the response from the consumer 30 is received(e.g. from the access device 36) at the payment processing network 26 orthe issuer 28.

Note that step 430 may still be done even if there is a verifiedresponse that exists. This may be done in order to build a largerdatabase of verified challenges. Similarly, even if there is anunverified response that the merchant 22 can process, a new challengemay be created and sent also in order to build a larger database ofverified challenges.

The determination of when a response, and thus the correspondingchallenge, is verified can depend on different factors. At least one ofthe factors is a similarity in the responses received.

III. Verifying Challenges and Determining Reliability of Responses

FIG. 5 is a flow diagram illustrating a method 500 for determining averified response during an authorization process according to anembodiment of the present invention. In step 510, an unverifiedchallenge is provided to a consumer 30 as previously described. In step520, the challenge response is received from the consumer 30 aspreviously described.

In step 530, the payment processing network server 26(a) and/or theissuer server 28(a) determines whether the response is the same orsimilar as one or more previous responses from the consumer 30. Similaranswers may be taken as well depending on the question. For example, ifthe difference is a small typographical error, then a consistencybetween the two answers may be inferred. For example, if the question isthe place of your birth and past responses have been “Kansas City”, thena misspelled response of “Kansas Ciry” may be taken to be the sameanswer.

In step 550, if it is determined that the response is the same aprevious response, then it is determined whether a verificationthreshold has been reached. In one embodiment, the verificationthreshold is simply a count for the number of times that the responsehas been similar. For example, if the response has been the same thelast N times, the response (and corresponding challenge) are deemedverified. The number N may be viewed as a threshold value, such that thecount is equal to or greater than N before is verified. Similarly, athreshold of N−1 could be used where the determination is whether thecount is greater than N. One skilled in the art will appreciate thebreadth of the types of embodiments possible.

In another embodiment, the verification threshold accounts for aconsistency across all or a certain segment of responses even if some ofthem have been wrong. The percentage of the last N responses that arecorrect may be used to determine whether the response is to be verified.Note that a minimum number of responses may be required. For example, ifat least 10 responses have been received, and at least 90% (9 responses)are similar then the response may be verified.

Other criteria may also be used besides the level of consistency in thesimilarity between responses. For example, the amount of time that theconsumer has had the portable consumer device may be also used. One wayof enumerating this amount of time is the number of billing cycles thatthe consumer has had the card. Thus, in one embodiment, if the answer issimilar three times in a row and the consumer has kept the card for 4billing cycles, then the challenge question/answer may be used in theauthorization process, e.g., to authenticate the consumer. Othercriteria can include whether there have been any charge backs on thecard (i.e. a transaction reversed is at a later time), where theresponses have been made (such as at home, a trusted merchant, orsomeplace else), or any other criteria mentioned herein or known to oneskilled in the art.

If it is determined that the response is not the same as a previousresponse, then an error control is performed in step 540. In oneembodiment, the error control process resets the count for the number oftimes that the response has been similar. In one aspect, this results ina restart of the seeding process. This may occur, for example, when theactual correct answer has changed. The consumer may have moved, and thushis zip code may actually be different; therefore, the inferred correctanswer will be different.

In another embodiment, the error control may do nothing, such as mightbe the case when a percentage of similar answers are being used. Othercriteria may be analyzed to determine if the seeding process should berestarted, such as looking at the recent activity on the credit card,where the current transaction is taking place, or other criteriamentioned herein. The error control may also perform other actionsrelated to safeguarding the account when the answer is different.

A verified challenge may also be affected by the response from theconsumer. For example, some challenge questions may be more reliable(confidence score) than other ones. The more reliable challengequestions may affect the risk score more. Thus, a more accurate andefficient risk may be achieved.

FIG. 6 is a flow diagram illustrating a method 600 for performing anauthorization of a transaction using a verified challenge responseaccording to an embodiment of the present invention. In step 610, averified challenge is provided by the issuer 28 and/or the paymentprocessing network 26 to a consumer 30 as previously described (e.g.,either using the mobile phone 34, portable consumer device 32, or accessdevice 36). In step 620, the challenge response is received from theconsumer 30 at the payment processing network 26 or the issuer 28.

In step 630, the payment processing network server 26(a) or the issuerserver 28(a) determines whether the response is the same or similar asone or more previous responses. This analysis may be performed as in thestep 530 of method 500.

In step 650, if it is determined that the response is the same as aprevious response, then a confidence score associated with the challengemay be increased. A confidence score reflects a level of how reliablethe response is for authenticating the identity of the consumer.Examples of a confidence score may be a value between 0 and 1, apercentage between 0 and 100, or any other suitable values, which mayhave any scaling factor.

The confidence score may increase differently each time the sameresponse is received. For instance, the confidence score might increasemore for the responses received earlier. A confidence score may alsoincrease less if suspect behavior had just occurred with the creditcard. Thus, other criteria may be affect the confidence score. Forexample, that the card has not been canceled can also increase thereliability (confidence score) or the risk score. Different confidencescores may also increase different amounts.

In one aspect, the confidence score may be used as a weighting indetermining the overall risk score, or similarly whether the user isconsidered to be authenticated. For example, an inconsistent (notsimilar) response to a challenge with a high confidence score will havea greater impact on the risk score than would an inconsistent response.Each challenge question posed during an authorization process may have adifferent confidence score.

In one embodiment, the confidence score simply multiplies a one or azero, depending whether that particular response is similar. In anotherembodiment, the confidence score is used in a more complex function asan input or an offset.

In one embodiment, the confidence scores of challenges that have justbecome verified will vary. In another embodiment, the confidence scoreof each verified challenge is the same (e.g. 30%) after it is verified.

In step 660, whether a similar response was received, along with thecorresponding confidence score, is used to determine a risk score for atransaction. In one embodiment, the newly updated confidence is used. Inanother embodiment, the confidence score after the last transaction isused. Past transactional information may be stored in a database such asthe transaction history database 26(b).

In step 640, an error control may be performed as in method 500 when theresponse is not similar. Even if the response is not similar, a riskscore may still be calculated. In one embodiment, as part of the errorcontrol, the challenge is labeled as not verified any more. In oneaspect, the verification process is completely restarted. Thus, thecount would be reset to zero or the percentage of similar responseswould be reset to 0%.

In another aspect, the verification process is started midstream. Forexample, the percentage of past responses that are viewed as similarmight not become 0% and the minimum number of transaction may already beconsidered as met (i.e. the responses of the last N transaction may bekept). The decision as to whether to completely restart the verificationprocess may be based at least in part on other criteria mentioned hereinand known to one skilled in the art. Once a challenge becomes verifiedagain, its confidence score may reflect the process of re-verification.That is a challenge that has become re-verified might have a lower orhigher confidence score than a challenge that has become verified for afirst time.

In another embodiment, the challenge stays verified, but its confidencescore is decreased.

Any of the servers 26(a), 28(a), and the access device 36 may utilizeany suitable number of subsystems. Examples of such subsystems orcomponents are shown in FIG. 7. The subsystems shown in FIG. 7 areinterconnected via a system bus 775. Additional subsystems such as aprinter 774, keyboard 778, fixed disk 779, monitor 776, which is coupledto display adapter 782, and others are shown. Peripherals andinput/output (I/O) devices, which couple to I/O controller 771, can beconnected to the computer system by any number of means known in theart, such as serial port 777. For example, serial port 777 or externalinterface 781 can be used to connect the computer apparatus to a widearea network such as the Internet, a mouse input device, or a scanner.The interconnection via system bus allows the central processor 773 tocommunicate with each subsystem and to control the execution ofinstructions from system memory 772 or the fixed disk 779, as well asthe exchange of information between subsystems. The system memory 772and/or the fixed disk 779 may embody a computer readable medium.

Embodiments of the invention provide for a number of advantages. Forexample, since challenge responses are verified on an “as you go” basis,embodiments of the invention do not require an issuer or paymentprocessing organization to amass challenge questions and answers beforea consumer starts conducting payment transactions (or money transfertransactions). If, for instance, a consumer does not conduct a greatnumber of payment transactions, then significant time and resources neednot be spent generating a collection of information for that consumer.Also, consumers are not required to “pre-register” before usingembodiments of the invention. A consumer need not fill out a form toprovide challenge response information up front. Thus, it is more likelythat many consumers will use embodiments of the invention sinceconsumers need not take the time to pre-register.

The specific details of the specific aspects of the present inventionmay be combined in any suitable manner without departing from the spiritand scope of embodiments of the invention. However, other embodiments ofthe invention may be directed to specific embodiments relating to eachindividual aspects, or specific combinations of these individualaspects.

It should be understood that the present invention as described abovecan be implemented in the form of control logic using computer softwarein a modular or integrated manner. Based on the disclosure and teachingsprovided herein, a person of ordinary skill in the art will know andappreciate other ways and/or methods to implement the present inventionusing hardware and a combination of hardware and software

Any of the software components or functions described in thisapplication, may be implemented as software code to be executed by aprocessor using any suitable computer language such as, for example,Java, C++ or Perl using, for example, conventional or object-orientedtechniques. Computer programs incorporating features of the presentinvention may be encoded on various computer readable media for storageand/or transmission; suitable media include magnetic disk or tape,optical storage media such as compact disk (CD) or DVD (digitalversatile disk), flash memory, and the like. The computer readablemedium may be any combination of such storage or transmission devices.

Such programs may also be encoded and transmitted using carrier signalsadapted for transmission via wired, optical, and/or wireless networksconforming to a variety of protocols, including the Internet. As such, acomputer readable medium according to an embodiment of the presentinvention may be created using a data signal encoded with such programs.Computer readable media encoded with the program code may be packagedwith a compatible device or provided separately from other devices(e.g., via Internet download). Any such computer readable medium mayreside on or within a single computer program product (e.g. a hard driveor an entire computer system), and may be present on or within differentcomputer program products within a system or network.

The above description is illustrative and is not restrictive. Manyvariations of the invention will become apparent to those skilled in theart upon review of the disclosure. The scope of the invention should,therefore, be determined not with reference to the above description,but instead should be determined with reference to the pending claimsalong with their full scope or equivalents.

A recitation of “a”, “an” or “the” is intended to mean “one or more”unless specifically indicated to the contrary.

All patents, patent applications, publications, and descriptionsmentioned above are herein incorporated by reference in their entiretyfor all purposes. None is admitted to be prior art.

1.-14. (canceled)
 15. A method comprising: receiving, from an entity, achallenge message for a consumer for a first time; providing, to theentity, a first challenge response that is responsive to the challengemessage; repeating receiving the challenge message and providing asubsequent challenge response during each of one or more processes forauthorizing a respective transaction initiated by the consumer in orderto provide a verified answer to the challenge message; receiving, fromthe entity, the challenge message during a process for authorizinganother transaction, wherein the challenge message is in response to anauthorization request message that is associated with the consumerconducting the another transaction with a portable consumer device andthat is sent to an issuer associated with the portable consumer device;and providing, to the entity, another challenge response suitable fordetermining an authorization response message that indicates whether ornot the another transaction is authorized, wherein the anothertransaction is more likely to be authorized if the another challengeresponse is similar to the verified answer.
 16. The method of claim 15wherein the entity is the issuer.
 17. The method of claim 15, furthercomprising: during the process for authorizing the another transaction,providing, by the consumer to the entity, one or more additionalchallenge responses that are respectively responsive to one or moreother challenge messages, wherein the transaction is more likely to beauthorized if the additional challenge responses are respectivelysimilar to previously provided challenge responses responsive to theother challenge messages.
 18. The method of claim 15, wherein aconfidence score is associated with the challenge message, and whereinthe confidence score is a measure of a likelihood that when the anotherchallenge response is dissimilar from the verified answer that theanother transaction will not be authorized.
 19. The method of claim 18wherein the confidence score increases when the another response issimilar to the verified answer.
 20. The method of claim 15, furthercomprising: when the another challenge response is dissimilar from theverified answer, repeating receiving the challenge message and providinga subsequent challenge response during each of one or more processes forauthorizing a respective transaction initiated by the consumer in orderto provide a re-verified answer to the challenge message.
 21. A computerprogram product comprising a computer readable medium encoded with aplurality of instructions for controlling a computing system to performan operation for facilitating a consumer in an authorization process fora transaction requested by the consumer, the operation comprising thesteps of: receiving, from an entity, a challenge message for a consumerfor a first time; providing, from the consumer to the entity, a firstchallenge response that is responsive to the challenge message;repeating receiving the challenge message and providing a subsequentchallenge response during each of one or more processes for authorizinga respective transaction initiated by the consumer in order to provide averified answer to the challenge message; receiving, from the entity,the challenge message during a process for authorizing anothertransaction, wherein the challenge message is in response to anauthorization request message that is associated with the consumerconducting the another transaction with a portable consumer device andthat is sent to an issuer associated with the portable consumer device;providing, to the entity, another challenge response suitable fordetermining an authorization response message that indicates whether ornot the another transaction is authorized, wherein the anothertransaction is more likely to be authorized if the another challengeresponse is similar to the verified answer.
 22. A phone comprising acomputer readable medium encoded with a plurality of instructions forcontrolling a computing system of the phone to perform an operation forfacilitating a consumer in an authorization process for a transactionrequested by the consumer, the operation comprising the steps of:receiving, at the phone being used by a consumer, a challenge messagefrom an entity for a first time; providing, to the entity using thephone, a first challenge response that is responsive to the challengemessage; repeating receiving the challenge message at the phone andproviding a subsequent challenge response using the phone during each ofone or more processes for authorizing a respective transaction initiatedby the consumer in order to provide a verified answer to the challengemessage; receiving, at the phone from the entity, the challenge messagefor the consumer during a process for authorizing another transaction,wherein the challenge message is in response to an authorization requestmessage that is associated with the consumer conducting the anothertransaction with a portable consumer device and that is sent to anissuer associated with the portable consumer device; and providing, tothe entity using the phone, another challenge response suitable fordetermining an authorization response message that indicates whether ornot the another transaction is authorized, wherein the anothertransaction is more likely to be authorized if the another challengeresponse is similar to the verified answer.
 23. A method of using aphone to facilitate an authorization process, the method comprising:receiving, at a phone being used by a consumer, a challenge message froman entity for a first time; providing, to the entity using the phone, afirst challenge response that is responsive to the challenge message;repeating receiving the challenge message and providing a subsequentchallenge response during each of one or more processes for authorizinga respective transaction initiated by the consumer in order to provide averified answer to the challenge message; receiving, from the entity,the challenge message during a process for authorizing anothertransaction, wherein the challenge message is in response to anauthorization request message that is associated with the consumerconducting the another transaction with a portable consumer device andthat is sent to an issuer associated with the portable consumer device;and providing, to the entity, another challenge response suitable fordetermining an authorization response message that indicates whether ornot the another transaction is authorized, wherein the anothertransaction is more likely to be authorized if the another challengeresponse is similar to the verified answer.
 24. The method of claim 15,wherein none of the subsequent challenge responses are used in adetermination of whether the consumer is authorized to make any of therespective transactions.
 25. The method of claim 15, wherein the entitycompares the another challenge response to the verified answer, whereinthe entity calculates a contribution to a risk score based on thecomparison, and wherein the risk score is used to determine whether ornot to authorize the another transaction.
 26. The method of claim 15,wherein the first challenge response is provided during a process ofauthorizing a transaction requested by the consumer.
 27. The method ofclaim 15, wherein the entity infers respective verified answers to oneor more other challenge messages, and wherein the entity may use theother challenge messages, their respective verified answers, andrespective challenge responses in the determination of the anothertransaction.
 28. The method of claim 15, wherein the entity infers theverified answer to the challenge message by determining a consistencyvalue for the provided subsequent challenge responses, comparing theconsistency value to a threshold value, and verifying the answer when athreshold criteria has been achieved.
 29. The method of claim 28,wherein the consistency value is a number of consecutive responses thathave been similar, wherein the threshold value is an integer N, andwherein the threshold criteria is whether the consistency value is atleast one of greater than N or greater than or equal to N.
 30. Themethod of claim 28, wherein the entity infers the verified answer basedalso on one or more other criteria.
 31. The method of claim 30, whereinthe other criteria includes a number of billing cycles that the consumerhas had a portable consumer device without suspect activity.
 32. Themethod of claim 15, wherein the entity resets a process of inferring theverified answer when the another challenge response is different thanthe verified answer.
 33. The method of claim 30, wherein the othercriteria further includes whether any of the respective othertransactions have been reversed.
 34. The method of claim 30, wherein theother criteria further includes a location of the consumer when thesubsequent challenge responses were provided.